Offline configuration and download approach

ABSTRACT

A system for creating a station having a configuration and making the station active within a supervisor application without a need of actual site controller hardware. The configuration may be changed. The new station may be downloaded with the changed configuration to a site controller. Multiple steps for effecting the present configuration design and station download may automatically be accomplished by fewer steps.

The present application is related to U.S. patent application Ser. No.12/260,046, filed Oct. 28, 2008, entitled “A Building ManagementConfiguration System”. U.S. patent application Ser. No. 12/260,046,filed Oct. 28, 2008, is hereby incorporated by reference. The presentapplication is also related to U.S. patent application Ser. No.12/703,476, filed Feb. 10, 2010, entitled “A Multi-Site Controller BatchUpdate System”; and U.S. patent application Ser. No. 12/643,865, filedDec. 21, 2009, entitled “Approaches for Shifting a Schedule”; all ofwhich are hereby incorporated by reference.

BACKGROUND

The invention pertains to software and controllers and particularly tocontroller configurations. More particularly, the invention pertains toconfiguration designing.

SUMMARY

The invention is an approach for creating a station with a configurationand making it active within a supervisor application without a need ofactual site controller hardware. The configuration may be changed. Thenew station may be downloaded to a site controller. The approach mayautomate multiple steps into one or more sequences of operations.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a flow diagram for an offline configuration and downloadapproach;

FIG. 2 is a flow diagram of a jar transfer which is one of the featuresin an offline configuration and download;

FIG. 3 is a diagram of interaction among a user, a supervisor, and acontroller;

FIG. 4 is a flow diagram of a user's case for a manual backup/restore;

FIG. 5 is a flow diagram of a restore for a redownload; and

FIGS. 6-25 are diagrams of screen shots showing significant portions ofa process of the present application or approach.

DESCRIPTION

The Tridium™ (Tridium) NiagaraAX™ (NiagaraAX, Niagara) Framework™(framework) may particularly be a base software application or approachfor developing a site offline configuration and download feature. Thefeature may capture improvements made to an existing Niagara Workbench™(workbench) user interface application to provide the customer a desireduser experience in creating controller configurations and deploying themto site controllers.

The Novar™ (Novar) Opus™ (Opus) Supervisor™ (supervisor) may provide abasis of the present application or approach. The framework maygenerally be a software platform for integrating diverse systems anddevices regardless of manufacturers, or communication protocols into aunified platform which can be managed and controlled in real time overan internet using a standard web browser. The supervisor may be asoftware platform built on the framework. The supervisor may communicatewith site controllers via an intranet or internet. A site controller maybe referred to as an XCM (executive control module) controller (XCM).

The supervisor may serve real-time graphical information displays tostandard web-browser clients and provide server-level functions such ascentralized data logging, archiving, alarming, real-time graphicaldisplays, master scheduling, system-wide database management, andintegration with Novar Enterprise™ (enterprise) software. The enterprisesoftware family may be used for energy analysis and business-criticalrequirements such as alarm handling, systems configuration, datacollection and performance monitoring.

A definition of “creating a site configuration offline” may indicatethat a site controller configuration is created and made active within asupervisor application without a need of actual site controllerhardware. A customer of a Novar retail business may wish to create asite configuration offline and, when complete, initiate a download ofthis configuration to a site controller. Upon completion of thedownload, the customer may want to have a copy of the downloaded siteconfiguration safely backed up within the supervisor. The customer maywant these operations to require minimal user interaction with thesupervisor application.

The NiagaraAX workbench may be capable of approaches for creating anoffline site controller configuration and then deploying it to a remotesite controller. However, there are numerous user interactions that maybe required to accomplish this task. The present approach may minimizethese user interactions by automating multiple steps into sequences ofoperations.

The following items are individual user manual steps which may berequired when using Niagara workbench technology. One may note that theterm “supervisor” may be used to refer to the workbench application. Thesteps may incorporate the following: 1) Use a toolbar option to create anew site controller station baseline configuration within thesupervisor; 2) Provide a unique station name based on guidelines usingbest practices; 3) Provide a unique port number for running within thesupervisor; 4) Navigate to an application director view within thesupervisor; 5) Select the newly created station and invoke a startcommand; 6) Connect the workbench to the running station within thesupervisor; 7) Perform site specific configuration additions andchanges; 8) Change the station to correct a port number for deployment;9) Stop the station running within the supervisor; 10) Connect theworkbench to a site controller platform service; 11) Navigate to thesoftware manager view; 12) Ensure that required jar (Java archive) filesare installed and up to date; 13) Navigate to the station copier view;14) Select the new station to download and initiate a download; 15)Connect the workbench to the newly deployed site controller; and 16)Initiate a backup operation to create a safe archive of the siteconfiguration. This set of steps may be simplified with some of thesteps being automatically performed by the present application orapproach.

The present application may provide the user an ability to create alogical, hierarchal structure representing the user's business and sitedeployment structure. A solution for the issue noted herein may be toprovide a user friendly, streamlined experience to create and deploy theuser's site configurations. Here, the user may perform the followingsteps: 1) Select a site node and use a right click menu option to createa new site controller station baseline configuration—This user action 1)may accomplish steps 1 through 6 specified for the related applicationor approach noted herein, by automatically performing the following foursub-steps: a) A unique station name may be constructed from hierarchalcomponent branch names; b) The application may assign a unique temporaryport number used while running in a supervisor; c) The station may bestarted within the supervisor environment; and d) The workbenchapplication may be connected to the running station; step 2) Performsite specific configuration changes which may include additions anddeletions—This may be the same user action as step 7 specified for therelated application or approach noted herein; 3) Set a site controllerIP address into an executive property sheet; 4) Select a new sitecontroller node and use the right click menu option for a download, andto initiate the download—This user action may accomplish steps 8 through16, specified for the related application or approach noted herein, byautomatically performing the following six sub-steps: a) The presentapplication or approach may stop the running station within thesupervisor and release the temporary port number; b) The application mayconnect to the site controller platform service; c) The application mayconfirm that required jar files are installed; d) The application mayperform a station download; e) The application may connect to the newlydeployed site controller; and f) The application may perform a backupoperation.

The present application or approach may be implemented as part of a“profiled” Niagara workbench. This means that the base workbench may beused as a basis and then extended to provide the desired user featureswhich are needed. The Niagara framework may provide a public applicationprogramming interface to allow many of the manual operations to beinitiated programmatically. To implement the present application, theapplication may consolidate the calls to the application programinterfaces (API's) into sequences and may be initiated by simple andintuitive menu options.

In the flow diagrams in the present description, various instances ofactions may be referred to as steps, blocks, actions, and the like.However, for illustrative purposes, the instances may be referred to asoccurring at the symbols in the respective diagrams.

FIG. 1 is a diagram which indicates an overall flow of the presentapproach. The approach may go from a start place 121 to a symbol 122where a new group, site and XCM may be created. At symbol 123, a stationmay be constructed with a unique station name. Additionally, a uniquetemporary port number may be assigned at symbol 124. The station may bestarted within a supervisor (i.e., begin a run mode) at symbol 125 to berunning. A user may perform site specific configuration additions andchanges at symbol 126. Changes may incorporate additions and deletions.At symbol 127, a download may be initiated. A question arises at symbol128 as to whether an XCM address is available for a download. If theanswer is no, then an XCM IP address may be accepted to download atsymbol 129 and then go to symbol 130, or if an address is already hadthen go to symbol 130 where the simulated station is stopped fromrunning (i.e., end the run mode or put into a non-run mode) at thesupervisor. Then a question of whether the JACE station is running maybe asked at symbol 131. If the answer is yes, then the station may bestopped at the XCM (JACE) as indicated at symbol 132. If the answer isno, then the station may be deleted at the XCM (JACE) at symbol 133. Aquestion at symbol 134 concerns whether the XCM has all of the requiredJAR files to initiate a download. If not, the all of the required JARfiles may be copied from the Opus client to the XCM (JACE) at symbol135. If the question is yes, then at symbol 136, the offline station maybe copied from the supervisor to the XCM. The XCM may be rebooted andthe station started at symbol 137. An enterprise hierarchy may becreated at the JACE level (i.e., Group->Site->XCM) according to symbol138. An initial backup may be initiated from the XCM to the supervisorat symbol 139. At symbol 140, the approach may be stopped.

FIG. 2 is a flow diagram of a jar transfer approach as it may relate toan offline configuration and download to a site controller. From a start11, there may be a module dependency list generated from config.Bog,platform.bog and px files at symbol 12. Opus™ (Opus) and Niagara relatedjars may be added to a generated list at symbol 13. At symbol 14, clientand XCM (executive control module) Niagara versions may be compared. Ifthe result of a comparison reveals the versions to be the same, then aninter-dependent module list may be generated from a client at symbol 15.If the result of the comparison reveals the versions to be different,then an inter-dependent module list may be generated from the XCM atsymbol 16 and the download may be continued at symbol 18.

After generating an inter-dependent module list from the client atsymbol 15, the availability of all of the dependent modules in the XCMmay be checked for at symbol 17. If all of the dependent modules areavailable in the XCM at symbol 17, then the download may be continued atsymbol 18. If all of the dependent modules are not available in the XCMat symbol 17, then all the missing modules may be transferred at symbol19 and on to continue download at symbol 18.

After generating an inter-dependent module list from the XCM at symbol16, the availability of all of the dependent modules in the XCM may bechecked for at symbol 21. If all of the dependent modules are availablein the XCM at symbol 21, then the download may be continued at symbol18. If all of the dependent modules are not available in the XCM atsymbol 21, then a question of whether a missing module list containsonly Opus jars may be asked at symbol 22. If the answer at symbol 22 isno, then the download may be stopped and the missing modules be shown atsymbol 24. If the answer at symbol 22 is yes, then the Opus modules maybe transferred at symbol 23 and the download continued at symbol 18.

FIG. 3 is a diagram of interaction activity of the user 41, Opussupervisor 42 and the XCM 43. User 41 may enter the XCM IP address andcredentials at a line 44 and initiate download( ) at a line 45 goingfrom the user 41 to supervisor 42. There may be a stop offline station() at line 46 going from user 41 to supervisor 42. From Opus supervisor42 to XCM 43, the items may include a stop running XCM station( ) at aline 47, a check( ) for dependency jars at line 49, a transfer dependentjars to XCM( ) at line 38, a delete existing XCM station( ) at line 48,a create new station at XCM( ) at line 52, a reboot XCM( ) at line 51, astart station in XCM( ) at line 39, a create enterprise hierarchy atXCM( ) at line 50, and an initial backup( ) at line 53. The Opussupervisor 42 may indicate to user 41 the XCM download as successful( )at line 54.

FIG. 4 is a flow diagram of a user's case for a manual backup/restore. Auser 56 may go to an Opus workbench 57 and then to an Opus supervisor 58to initiate a backup in an XCM node at symbol 59. Then a backup dist(distribution) file may be generated at symbol 61.

FIG. 5 is a flow diagram of a restore for a redownload. A user 81 may goto an Opus workbench at symbol 82 and connect to an Opus supervisor atsymbol 83. At symbol 84, the user 81 may initiate a restore for aredownload at a dist file under a backup folder. The dist filed may berestored at the supervisor for an offline simulation at symbol 85. Adownload flag set to false at symbol 86 may be included in the action atsymbol 85.

FIGS. 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22,23, 24 and 25 are diagrams of screen shots 101, 102, 103, 104, 105, 106,107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, and 119,respectively, which show portions of a process of the presentapplication. The screen shots are from a demonstration provided by aWebEx™ player with a label 91, as shown in screen shot 101 of FIG. 6,revealing the time of each screen shot taken during the process.

In the present specification, some of the matter may be of ahypothetical or prophetic nature although stated in another manner ortense.

Although the present system has been described with respect to at leastone illustrative example, many variations and modifications will becomeapparent to those skilled in the art upon reading the specification. Itis therefore the intention that the appended claims be interpreted asbroadly as possible in view of the prior art to include all suchvariations and modifications.

1. A method for offline configuring and offloading, comprising: creatingin a software platform, outside of a site controller, an offline stationhaving a configuration; running the offline station; changing theconfiguration; and providing an address for the offline station;stopping the offline station; stopping an existing station at the sitecontroller; deleting the existing station; and downloading the offlinestation to the site controller.
 2. The method of claim 1, furthercomprising: rebooting the site controller; and starting the offlinestation at the site controller.
 3. The method of claim 2, furthercomprising backing up the offline station from the site controller tothe software platform.
 4. The method of claim 1, wherein the softwareplatform is a supervisor.
 5. The method of claim 1, wherein the addressfor the offline station comprises a unique station name.
 6. The methodof claim 1, wherein the address for the offline station comprises aunique temporary port number.
 7. The method of claim 1, furthercomprising assuring that required jar files are at the site controllerprior to downloading the offline station to the site controller.
 8. Themethod of claim 2, further comprising creating an enterprise hierarchyafter rebooting the site controller and starting the offline station atthe site controller.
 9. The method of claim 1, wherein: the softwareplatform is an OPUS supervisor; and the site controller is an XCMcontroller.
 10. An offline configuring system comprising: a softwareplatform; and an offline station having a configuration on the softwareplatform; and wherein: the offline station is put into a run mode;changes are made to the configuration; the offline station is put into anon-run mode; a site controller is checked to note if an existingstation is in a run mode; if the existing station is in a run mode, thenthe existing station is put into a non-run mode and eliminated; and theoffline station is downloaded to the site controller.
 11. The system ofclaim 10, wherein: the site controller is rebooted; and the offlinestation is put into the run mode at the site controller.
 12. The systemof claim 11, wherein the offline station is backed up from the sitecontroller to the software platform.
 13. The system of claim 10, whereinprior to the offline station being downloaded to the site controller,the site controller has all needed jar files.
 14. The system of claim11, wherein: the software platform is a supervisor; and an enterprisehierarchy is created at the site controller.
 15. The system of claim 10,wherein: the offline station has a unique station name; and the offlinestation is assigned a temporary port number.
 16. The system of claim 10,wherein the software platform is an OPUS supervisor; and the sitecontroller is an XCM controller.
 17. A method for providing offlineconfiguring and offloading, comprising; selecting a site node in asupervisor environment; clicking a menu option to create a new sitecontroller station baseline configuration; performing site specificconfiguration changes; setting a site controller IP address into anexecutive property sheet; selecting a new site controller node; andclicking a menu option for a download.
 18. The method of claim 17,wherein selecting site node and clicking a menu option to create a newsite controller station baseline configuration automaticallyaccomplishes the following: constructing a unique station name;assigning a unique temporary port number used while running in thesupervisor environment; starting the station within the supervisorenvironment; and connecting a workbench application to the runningstation.
 19. The method of claim 17, wherein the selecting a new sitecontroller node and clicking on a menu opinion for a downloadingautomatically accomplishes the following: stop the running stationwithin the supervisor environment and release the temporary port number:connect to a site controller platform service; confirm an installationof jar files as required to a newly deployed site controller; perform astation download; connect to the newly deployed site controller; andperform a backup operation of the station at the newly deployed sitecontroller.
 20. The method of claim 19, wherein the supervisorenvironment is of an OPUS supervisor; and the newly deployed sitecontroller is an XCM controller.